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(57) Data structures and various methods for invok- 
ing and creating objects are used in a distributed object 
system in order to implement subcontracts. A subcon- 
tract is a selected grouping of basic features or object 
mechanisms that a system provides for use in manag- 
ing objects and has associated functions. A subcontract 
registry is used for creating object references for server 
objects. The subcontract registry has any number of 
subcontract objects within it, and each subcontract 
object may include: a subcontract identifier that identi- 
fies the subcontract object, a quality of service list that 
contains feature name-value pairs, and a create func- 
tion unique to the subcontract object. An implementa- 
tion registry is used for registering any number of 
implementation definitions. Each implementation defini- 
tion defines an implementation for an interface within 
the system, and each implementation definition may 
include: an implementation identifier that identifies the 
implementation, a pointer to a subcontract object con- 
tained in the subcontract registry, an interface identifier 
that identifies the interface being implemented, and a 
set of functions used for creating and invoking a server 
object that are unique to that implementation. One 
method creates an object reference for a distributed 
server object by using the subcontract registry in order 
to identify the unique create function to be used that cor- 
responds to the subcontract functionality desired. 
Another technique invokes a method defined on a 
server object by using an object reference to find the 
appropr i at e i mp le m e ntat i on d e f i nit i on i n t he i m p lemen- 



tation registry. Lookup and dispatch functions unique to 
this definition are used to invoke the method. 
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Description 

CROSS REFERENCE TO RELATED APPLICATIONS 

U.S. patent application "Method and Apparatus for 
Subcontracts in Distributed Processing Systems", 
Serial No. 08/554,794 filed November 7, 1995, a contin- 
uation of Serial No. 07/995,863, filed December 21, 
1992, now abandoned, is related to the present applica- 
tion and is incorporated by reference herein in its 
entirety. Additionally, the following U.S. Patent Applica- 
tions, all filed concurrently herewith, are related to the 
present application and are incorporated by reference 
herein in their entirety: Serial No. 

Attorney Docket No. 

SUN1P078; Serial No. Attorney 

Docket No. SUN1P082; Serial No. 

Attorney Docket No. 

SUN1P085; Serial No. Attorney 

Docket No. SUN1P083; and Serial No. 

, Attorney Docket No. 

SUN1P079. 

FIELD OF THE INVENTION 

The present invention relates generally to distrib- 
uted object systems. More specifically, the present 
invention relates to a low overhead object adaptor within 
a distributed object system that is able to apply selected 
features in such a system to the use of individual 
objects. 

BACKGROUND OF THE INVENTION 

With the increasing popularity of object-oriented 
programming languages and systems, the development 
of distributed object systems has presented new chal- 
lenges regarding the creation, referencing, invocation 
and use in general of the objects within these distributed 
systems. It has become common to provide remote pro- 
cedure call (RPC) facilities that extend the semantics of 
local procedure calls to these distributed object sys- 
tems. This often takes the form of remote object invoca- 
tion. However, rather than there being a single set of 
obvious semantics for all remote objects, there appears 
to be a wide range of possible object semantics, often 
reflecting different application requirements. For exam- 
ple, there are distributed object systems that include 
integrated support for the features of replication, atomic 
transactions, object migration, and persistence. But 
there are also distributed object systems that provide 
only minimal features and instead concentrate on high 
performance. 

One possible reaction to this diversity is to attempt 
to design a single distributed object system for remote 
objects that includes all possible features. Unfortu- 
nately, the list of possible features is continually expand- 
ing, and not all features are necessarily compatible. For 
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example, a high performance system may not want its 
objects to include support for the features of persistence 
or atomicity. Moreover, there are often a variety of differ- 
ent ways of implementing a given set of semantics. Hav- 

5 ing a single system prevents applications from 
exploiting new and improved features that may better 
reflect their real needs. For example, in order to 
increase reliability, it may be desired to support the fea- 
ture of object replication. However, it would not be desir- 

10 able to have client application code doing-extra work 
simply to talk to replicated objects, so it would be prefer- 
able to support replication "underneath the covers", as 
part of the object's invocation mechanism. But there are 
many different ways of implementing replication, and it 

15 is undesirable to build in support for some particular set 
of features while implicitly rejecting others. 

There are a wide variety of features or object mech- 
anisms that a distributed object system might provide. 
By way of example, a distributed object system may pro- 

20 vide such features such as replication, atomic transac- 
tions, object migration, persistence, naming, event 
notification, relationships, server activation, clean shut- 
down, transactions, security, and enablement of filters 
(compression, encryption, tracing, debugging, etc.). 

25 These features may also be called services and may be 
provided by an Object Services module as part of a dis- 
tributed object system. Past distributed object systems 
have suffered in that they were unable to provide a flex- 
ible subset of these features for different applications, 

30 much less for different objects within an application. 
Past systems only provided a fixed set of these features. 

This deficiency may be addressed through the 
notion of a subcontract. Subcontracts and their use are 
described in the above-referenced patent application 

35 Serial No. 08/554,794. The notion of a subcontract is 
also described in "Subcontract: A Flexible Base for Dis- 
tributed Programming" by G. Hamilton, M. Powell and J. 
Mitchell, published by Sun Microsystems Laboratories, 
Inc., 1993. Subcontracts and their associated function- 

40 ality may be implemented in many different ways. 

Through the use of subcontracts, an application 
may specify which of the various above features (among 
others) it wishes to take advantage of, or may even 
specify different groups of features that may be used by 

45 different objects within the application. A group or a per- 
mutation of these features is termed a subcontract. 
Thus, each object within an application may utilize a 
particular subcontract (or group of features). A group of 
desired features is also termed a desired a quality of 

so service And these desired features may be repre- 
sented in a quality of service fist. A subcontract, then, 
delivers a particular quality of service within a distrib- 
uted object application An object may have one sub- 
contract associated wrth it at a given time. Subcontracts 

55 are separate from object interfaces and object imple- 
mentations. Thus, it ts easy for object implementers to 
either select and use an existing subcontract, or to 
implement a new subcontract. Correspondingly, appli- 
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cation level programmers need not be aware of the spe- 
cific subcontracts that are being used for particular 
objects. A subcontract associated with an object allows 
the business of implementing an object to be separate 
from the business of implementing the object mecha- 5 
nisms or features provided by the system. 

One of the reasons that subcontracts are effective 
is because they separate out the business of imple- 
menting objects from implementing object mechanisms. 
The availability of subcontracts enable object imple- 10 
menters to choose from a range of different object 
mechanisms (or features) without requiring that every 
object implementer must become familiar with the 
details of the object implementation machinery. The set 
of features that subcontracts provide are the right levers is 
for obtaining control within a distributed environment. By 
design, all of the key actions taken on remote objects 
will involve the object's subcontract in one way or 
another. By way of example, actions such as object cre- 
ation, object reference creation and method invocation 20 
involve the object's subcontract. Subcontracts provide 
an effective way for plugging in different policies for dif- 
ferent objects and are successful in reducing the func- 
tionality that must be provided by the base system. 

However, conventional distributed object system 25 
have not utilized the functionality of subcontracts and 
are not well adapted to integrating subcontracts. The 
common object request broker architecture (CORBA), 
defines the notion of an object adaptor. Among other 
tasks, an object adaptor creates servant objects and 30 
dispatches requests to a server. Object adaptors pro- 
vide a limited set of choices about the server-side object 
mechanisms. However, most object adaptors are sup- 
plied as part of the basic object machinery, and it is not 
realistically possible for application writers to implement 35 
new object adaptors, or for the object machinery to dis- 
cover and install new object adaptors at run time. For 
example, the Basic Object Adaptor (BOA) defined under 
CORBA is very limited in that it only provides a fixed set 
of features. As discussed above, it is less than desirable 40 
that an object only be provided with a fixed set of fea- 
tures. And even if alt features are supplied, this comes 
at the expense of performance, and vice-versa. How- 
ever, one object in a particular application may only 
need to utilize a limited set of features, as contrasted 45 
with a different object in the same application that needs 
a different set of features. Thus, prior art object adap- 
tors may unnecessarily burden objects with extra fea- 
tures resulting in high overhead and increased use of 

CPU time. 50 

Accordingly, the creation of a mechanism that is 
able to implement some of the traditional object adaptor 
functions, while at the same time, being capable of tak- 
ing advantage of the use of subcontracts would be 
desirable. Such an object adaptor would overcome the ss 
shortcomings of fixed Object Adaptors in that it would 
permit different objects within a distributed system to 
take advantages of some, but not necessarily all of the 



features provided by the distributed object system. 



SUMMARY OF THE INVENTION 

Embodiments of the present invention relate to data 
structures for use with subcontracts as well as various 
methods for invoking and creating objects. One data 
structure is a subcontract registry embodied in a com- 
puter-readable medium. The subcontract registry is 
used for creating object references for server objects 
within a distributed object computing system. The dis- 
tributed object computing system may provide a number 
of features (or object mechanisms) for use in the crea- 
tion of object references for server objects. The subcon- 
tract registry has any number of subcontract objects 
within it, and each subcontract object contains informa- 
tion relating to a particular subcontract. That information 
may include: a subcontract identifier that identifies the 
subcontract object and a quality of service list that con- 
tains feature name-value pairs. The feature name iden- 
tifies one of the features that the particular subcontract 
may provide, and the value may indicate whether the 
feature is present or not, or may further qualify the fea- 
ture name. Also included is a create function unique to 
the subcontract object. The create function is used to 
create and return an object reference for a server object 
by way of using the features identified by the feature 
names in the quality of service list. 

Another data structure is the implementation regis- 
try, also embodied in a computer-readable medium. The 
implementation registry is used for registering any 
number of implementation definitions. Each implemen- 
tation definition defines an implementation for an inter- 
face within a distributed object computing system, and 
each implementation definition contains information 
relating to that implementation. That information may 
include: an implementation identifier that identifies the 
implementation, a location indicator to a subcontract 
object contained in the subcontract registry, an interface 
identifier that identifies the interface being implemented, 
and a set of functions used for creating and invoking a 
server object that are unique to that implementation. 

One embodiment of the present invention relates to 
a method of creating an object reference for a distrib- 
uted server object within the distributed object comput- 
ing system. The method begins by requesting that an 
object reference be created for a server object. Then, a 
subcontract in the subcontract registry is identified that 
corresponds to the server object to be created. This 
subcontract will have a quality of service list that identi- 
fies the quality of service to be utilized in invoking an 
implementation of the server object. The create function 
of the subcontract is also identified. The create function 
is responsible for creating the server object in a manner 
corresponding to the quality of service list. The create 
function is invoked in order to produce an object refer- 
ence for the server object, which is returned to the call- 
ing entity. 
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Another embodiment relates to invoking a method 
defined on a distributed server object. Initially, a mar- 
shal buffer containing an object reference to the server 
object is received. Once received, an, implementation 
identifier is extracted from the object reference. An 
implementation definition within the implementation reg- 
istry is also determined by using the extracted imple- 
mentation identifier as a key. A lookup function of the 
implementation definition is then called in order to pro- 
duce a location indicator to the server object. Once the 
location indicator is produced, a skeleton dispatch func- 
tion of the implementation definition is called in order to 
invoke the object method defined on the server object. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The invention, together with further advantages 
thereof, may best be understood by reference to the fol- 
lowing description taken in conjunction with the accom- 
panying drawings in which: 

Figure la illustrates a distributed object system 
having an object request broker (ORB) portion, 
object development facilities and client and server 
objects according to one embodiment of the 
present invention. 

Figure 1b shows the flow of a request from a client 
to a servant object within the distributed object sys- 
tem of Figure 1a. 

Figure 2 shows a subcontract registry table having 
various subcontract meta objects as entries accord- 
ing to one embodiment of the present invention. 

Figure 3 shows an implementation registry table 
having various implementation definitions as 
entries according to one embodiment of the present 
invention. 

Figure 4 shows graphically the interaction between 
the subcontract registry and implementation regis- 
try tables of Figures 2 and 3. 

Figure 5 is an embodiment of an object reference 
suitable for use within the distributed object system 
of Figures 1a and 1b. 

Figure 6 is a flowchart for implementation initializa- 
tion and invocation dispatching within a distributed 
object system according to one embodiment of the 
present invention. 

Figure 7 shows the create implementation definition 
step of Figure 6. 

Figure 8 shows the prepare implementation defini- 
tion step of Figure 6. 



Figure 9 shows the create object reference step of 
Figure 6. 

Figure 10 shows the deactivate implementation 
5 step of Figure 6. 

Figure 1 1 shows the shutdown step of Figure 6. 

Figures 12a and 12b are a flowchart for invoking a 
w method of a server object using a particular sub- 
contract. 

Figure 13 is the skeleton dispatch function step of 
Figure 12b. 

15 

Figure 14 is a typical computer system suitable for 
implementing the present invention. 

DETAILED DESCRIPTION OF THE INVENTION 

20 

OVERVIEW 

The present invention is directed toward distributed 
object systems and will be described with reference to 

25 several preferred embodiments as illustrated in the 
accompanying drawings. The invention may be prac- 
ticed within the context of any suitable distributed object 
system, including those defined under CORBA or any 
other suitable specification. However, for purposes of 

30 illustration, an embodiment of the present invention will 
be described primarily within the context of an Object 
Request Broker (ORB) implemented under the CORBA 
specification from the Object Management Group 
(OMG), Revision 2.0, dated July 1 995, which is incorpo- 

35 rated herein by reference. Figure 1a diagrammatically 
illustrates the overall architecture of a representative 
distributed object system suitable for implementing an 
embodiment of the present invention. Figure 1b dia- 
grammatically illustrates some possible flow paths that 

40 a request from a client to a servant object may follow 
within such an architecture that includes a three-level 
dispatch mechanism. Figure 5 shows one object refer- 
ence data structure that may be used by a client to refer 
to a servant object. 

45 A distributed object system 1 0 typically includes an 
Object Request Broker (ORB) 11 as is symbolically 
illustrated in Figure 1a. ORB 1 1 provides all of the loca- 
tion and transport mechanisms and facilities necessary 
to deliver a call from a client to a servant (target object) 

so and to return a response to the client, as will be dis- 
cussed below with reference to Figure 1b. The client 
and servant may be located in the same process, in dif- 
ferent processes on the same machine, or on com- 
pletely different machines. For the purposes of this 

55 discussion, client 20 may be any code that invokes an 
operation on a distributed object and thus may or may 
not take the form of a distributed object or a process. A 
distributed object may have a wide variety of represen- 
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tations. By way of example, the distributed object may 
be a C++ object that has been provided by an applica- 
tion developer. Alternatively, an implementation for a 
distributed object may be developed within a visual 
application builder 15. This visual application builder 5 
allows a developer to visually select existing object 
types from a catalog and graphically connect the serv- 
ices provided by one object to the services needed by 
another (attributes, arguments, results etc.) in order to 
create a new implementation for an object. 10 

An object development facility 16 may be used to 
simplify the creation and the installation of distributed 
objects. It is used to "wrap" or encapsulate developer 
objects in distributed object code. As such, object devel- 
opment facility 1 6 may be used to transform a developer 15 
object into an ORB object implementation 14. In this 
example, ORB object implementation 14 is presented 
as a server as shown by its location in the diagram. A 
developer uses an interface definition language to 
define an interface for an ORB object, provides a devel- 20 
oper object implementation that implements that 
object's behavior, and then uses the object develop- 
ment facility 16 in order to produce an ORB object 
implementation 14. At run time, an instance of this ORB 
object (a servant object) is created that will utilize this 25 
ORB object implementation 14. It should be appreciated 
that the object development facility may also be used to 
create objects that take the role of clients at some point. 

Client 20 communicates with a servant by way of a 
stub 21 , a subcontract layer 36, possibly a filter 40, and 30 
a transport layer 38. Stub 21 includes a surrogate 22, a 
method table 24 and stub functions 25. Client 20 com- 
municates initially with surrogate 22 that appears to the 
client as the servant object. Alternatively, client 20 may 
communicate directly with the servant object through a 35 
dynamic invocation interface (DM) 26 instead of through 
surrogate 22, method table 24 and stub functions 25. 
Dynamic invocation interface 26 is used to enable cli- 
ents to construct dynamic requests. One procedure by 
which a client may make a call to a servant utilizing the 4c 
above layers is described in more detail below with ref- 
erence to Figure 1b. 

Subcontract layer 36 provides the functionality 
required by an object in order to utilize subcontracts to 
implement various services (or features or object mech- 4; 
anisms) named by a particular subcontract, as 
described in greater detail in above-referenced U.S. 
Patent Application Serial No. 08/554,794, filed 
11/07/95. A subcontract identifies a quality of service 
provided by the distributed object system that may be 5. 
utilized by an individual object. For example, a subcon- 
tract may identify that the feature of security is to be 
used for a particular object. Filter 40, if being used, may 
perform a variety of tasks, such as compression, 
encryption, tracing, or debugging, that are to be applied s 
to communications to and from an object. 

Transport layer 38 operates to marshal, unmarshal 
and physically transport information to and from a serv- 



ant that typically does not share the same process as a 
client. 

A standard implementation suite 28 (or object 
adapter) represents a set of subcontracts that interact 
with ORB objects 14 in identical ways, as for example 
object key management. One such implementation 
suite is described in the below description of the present 
invention. It should be noted that a subcontract may 
belong to multiple implementation suites. Also, imple- 
mentation suites may utilize different "subcontracts. A 
skeleton, that may take the form of either static skeleton 
32 or dynamic skeleton 30, is used to transform 
requests into a format required by a servant object 78 
(as will be explained in more detail below with reference 
to Figure 1b). Thus, skeletons 30 and 32 call an appro- 
priate servant object 78. Static skeleton 32 is used to 
call interface-specific object implementations 14, while 
dynamic skeleton 30 is used generically when interface- 
specific objects are not available. An ORB interface 34 
is the interface that goes directly to the ORB that is the 
same for all ORBs and does not depend upon an 
object's interface or object adapter. 

An ORB daemon 46 is responsible for ensuring that 
object servers are active when invoked by clients. A 
technique for starting object servers is disclosed in U.S. 
Patent Application Serial No. 08/408,645 which is 
hereby incorporated by reference. 

Secure Protocol 42 is a secure interoperability pro- 
tocol that secures the internet inter-ORB protocol and 
helps to transmit information through transport layer 38 
in a secure fashion. This may mean integrity protection, 
confidentiality, etc. The internet inter-ORB protocol is a 
protocol that typically communicates between proc- 
esses on different machines. However, in some cases, 
the internet inter-ORB protocol may communicate 
between processes on the same machine. The security 
server 54 is a security administration server that 
secures the services that are used between processes 
on different computers. 

Typecode/Any module 44 implements "Typecode" 
and "Any" objects. Typecode describes an Interface 
Definition Language (IDL) data type, allowing type 
descriptions to be transmitted between clients and serv- 
ers. An instance of an IDL data type may be encapsu- 
lated by an Any object. An Any object refers to typecode 
of the encapsulated data, and a generic encoding of the 
data. 

An implementation repository 50 is used to store 
information relating to object servers. Specifically, 
implementation repository 50 stores the information 
needed to start a server process. For example, imple- 
mentation repository 50 stores information such as the 
location of the server program, any arguments to the 
program, and any environment variables to pass to the 
program, etc. 

Simple persistence 56 uses an Interface Definition 
Language (IDL)-defined type and the output from run- 
ning that IDL type through the IDL compiler, together 
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with a portion of additional code so that an IDL-defined 
type can be read from, and written to, disk. A naming 
service 52 is used to name ORB objects. A client may 
use naming service 52 to find a desired object by name. 
Naming service 52 returns an object reference, that in 
turn may be used to send requests to that object. An 
Interface Repository 48 (IFR) knows about all interfaces 
for all objects within the distributed object system. 

A request made by a client using a method table 
("m-table") dispatch will pass through a variety of the 
aforementioned layers of the architecture on its way to 
the servant as diagrammatically illustrated in Figure 1b. 
The request is initiated by a client and may take any 
suitable form. The form of the request will depend to a 
large extent upon the nature of the programming lan- 
guage used to create the client. By way of example, if 
the client is written in the C++ language, the request 
may take the form of a C++ method call 62. The call is 
made to a designated object reference taking the form 
of a surrogate. The surrogate includes methods that 
comply with the object's interface. 

As will be appreciated by those skilled in the art, the 
object reference used at different locations within a dis- 
tributed object system may vary significantly in appear- 
ance. In the embodiment described, the client side 
object reference is a dual pointer (referred to herein as 
a "fat pointer"). A fat pointer contains two distinct point- 
ers. A first pointer points to a client representation ("cli- 
ent rep") associated with the referenced object. A 
second pointer points to a method table of the method 
table dispatch 24 that is associated with the referenced 
object. A client representation is an object that has 
methods that support invocation as well as CORBA 
defined "pseudo" object reference operations. These 
operations include, but are not limited to, a "duplicate" 
method, a "release" method, a "narrow" method, a 
"hash" method, and an "is equivalent" method. 

After the client has initiated a call, the call is proc- 
essed using a method table dispatch mechanism 24. 
Such a technique is disclosed in U.S. Patent Application 
Serial No. 08/307,929 and is hereby incorporated by 
reference. 

The method table dispatch mechanism uses a 
method table that contains a list of location indicators to 
stub functions 25, one of which is associated with the 
method to be invoked. Stub functions 25 receive a func- 
tion or procedure call in the "native" language of the cli- 
ent process, then use either a subcontract layer 36 or a 
native call to eventually call the corresponding servant 
object. The native language may be any suitable lan- 
guage, as for example a language such as C++. 

Method table dispatch 24 determines the appropri- 
ate one of the stub functions 25 to process the method 
call, and then pairs the method call with the appropriate 
stub function. In the event that the client making the 
method call is in the same process as the servant 
object, a local stub function is called. The local stub 
function sends the method call directly to servant object 



78. Alternatively, if the servant object is in a different 
process, i.e. a remote process, a remote stub function is 
called. The remote stub function invokes the client rep- 
resentation, that delivers the invocation to servant 

5 object 78. 

Subcontracts implemented by subcontract layer 36 
are logic modules that provide control of the basic 
mechanisms of object invocation and argument passing 
that are important in distributed object systems. A sub- 

10 contract implemented by subcontract laye? 36 deter- 
mines a specific quality of service for use by an object. 
A subcontract is uniquely identified by a subcontract 
identifier that is typically embedded in an object refer- 
ence. A quality of service is a set of service properties. 

is Among possible service properties that are selectable 
are qualities relating to server activation, security, trans- 
actions, filterability, and clean shut-down. Subcontracts 
are configured such that certain qualities of service are 
available. With predetermined qualities of service, the 

20 overhead associated with processing individual service 
properties is reduced. Realistically, only "reasonable" or 
commonly used combinations of service properties are 
supported with subcontracts. However, subcontracts 
may be created to meet the specific requirements of a 

25 given distributed object system. 

The identification of an appropriate subcontract in 
subcontract layer 36 may be thought of as the identifica- 
tion of a desired function that is unique to that subcon- 
tract. For example, a marshal function or an unmarshal 

30 function is defined for each subcontract. A subcontract 
marshal function is used by a stub to marshal an object 
reference so that it may be transmitted to another 
address space, or domain. The object reference is typi- 
cally processed by a transport mechanism in transport 

35 layer 38. 

A transport mechanism such as T1, T2, etc., that is 
a part of the transport layer 38 is used to marshal and 
physically transport information to and from servant 
objects. Information, i.e. the object reference or the 

40 request, is converted into protocols appropriate to a 
given domain. By way of example, protocols may 
include, but are not limited to, Ethernet protocols and 
general inter-ORB protocols (GIOPs). In some uncom- 
mon cases, protocols may even entail the use of elec- 
ts tronic mail to transmit instructions to be implemented on 
a server. After information is marshaled, the transport 
mechanism then transports information through any 
combination of an operating system, a device driver, or 
a network, that are all a part of hardware 70 used by the 

so client side of a distributed object system. 

While transport mechanisms require a conversion 
of information into a protocol appropriate to a given 
domain, some transport mechanisms do not require the 
encoding of information for different domains. One 

55 transport mechanism that does not require a conversion 
of information into a protocol appropriate to a domain 
other than the one on which information originates is 
termed a "door". Doors are essentially gateways 
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between two different processes on the same host. The 
use of doors eliminates the need for a conversion of 
information into a canonical implementation in transport 
layer 38, as there is no need to encode information into 
a protocol that may be used by a different machine by 5 
virtue of the fact that information is remaining on the 
same host and therefore does not require a change of 
domain. Hence, information may simply be "flattened 
out," or marshaled into a stream that is not encoded for 
use by a different machine, and passed between the 10 
two processes on the host. 

Once information is transported through hardware 
70 used by the client side, the information is then trans- 
ported to hardware 70 on the server side of a distributed 
object system. Once information is routed through hard- 15 
ware 70, the server side of a distributed object system 
invokes a transport mechanism such as T1, T2 etc. to 
receive information on an end point that is a part of 
transport layer 38. In the event that an end point is not 
created by transport layer 38, transport layer 38 pro- 20 
vides the functionality needed for the end point to be 
created by subcontract layer 36. By way of example, a 
dedicated end point is typically created by subcontract 
layer 36, while cluster end points, which typically include 
network and TCP/IP end points, are typically created by 25 
transport layer 38. Regardless of whether end points 
are created by subcontract layer 36 or transport layer 
38, end points live in," i.e. are a part of, transport layer 
38. End points are essentially ports that receive infor- 
mation from a different domain. After an end point in 30 
transport layer 38 receives information transported from 
a different domain, the end point then dispatches the 
information from transport layer 38 to subcontract layer 
36. Subcontract layer 36 then dispatches the informa- 
tion to the skeleton and the servant. 35 

Subcontract layer 36 provides the functionality to 
unmarshal at least some of the information it has 
received. That is, subcontract layer 36 unmarshals at 
least part of the request. Then, the request is dis- 
patched to a skeleton 31 that transforms the request 40 
into an implementation specific format required by serv- 
ant object 78. The skeleton 31 may either be a static 
skeleton 32 or a dynamic skeleton 30 as described 
above. 

In general, a remote request is routed through the 45 
client side and the server side as described above. The 
method call 62 is received, method table dispatch layer 
24 is used to identify an appropriate subcontract prior to 
the selection of a transport mechanism in transport 
layer 38 that marshals the request and prepares it for so 
transport to another domain. Through hardware 70, the 
marshaled request is transported to the server side 
where it is received on an end point that is a part of 
transport layer 38. An appropriate end point receives 
information transported across a wire, and information 55 
is dispatched from transport layer 38 to subcontract 
layer 36, that provides the functionality to at least par- 
tially unmarshal the information it has received. The 



subcontract layer then dispatches the request to skele- 
ton 31 that transforms the request into a specific format 
required by servant object 78. This path is shown by 
arrow 77, and is the path that may be taken by both 
remote and local requests. 

However, if a client and a server are in a local proc- 
ess, i.e. both the client and the server are in the same 
process, the use of the path shown by arrow 77 as 
described above is unnecessarily complex. If it is known 
that the client and the server are in the same process, it 
is possible to shorten the invocation path, or flow path of 
a request for service. If a local process may be identified 
when an object reference is created, shortened flow 
paths, i.e. the paths represented by arrows 75 and 76, 
may be taken to send a request from a client to a server 
that are on the same host. The path represented by 
arrow 76 is more likely to be taken, as it uses subcon- 
tract layer 36 to identify an appropriate subcontract. 
However, in situations in which an appropriate subcon- 
tract does not need to be explicitly identified, the path 
represented by arrow 75 may be taken. 

Figure 5 will now be used to describe an embodi- 
ment of an object reference. As will be familiar to those 
skilled in the art, object references may take a variety of 
forms depending upon the location within the process 
that they are being held at any given time. However, by 
way of background, a representative object reference 
for use in a system that utilizes a low overhead imple- 
mentation suite is illustrated in Figure 5. In the imple- 
mentation shown therein, object reference 150 includes 
a host identifier 152, a port designation 154, and an 
object key 156. Object key 156 includes a subcontract 
identifier 158, a server identifier 160, an implementation 
identifier 162, and a user key 164. Host identifier 152 
denotes a particular computer in a network, while port 
designation 154 identifies the port of the selected com- 
puter that is to be used for communication. Object key 
156 provides further identifying information used in 
order to locate a desired servant object on its host 
machine. 

Server identifier 160 names a particular process or 
program in which the servant object resides, while user 
key 164 is a unique number or string used to locate the 
servant within the process named by server identifier 
1 60. Subcontract identifier 1 58 is used to attach the pro- 
tocol of a particular subcontract and its associated serv- 
ices with a servant, and implementation identifier 162 
names an implementation of an interface that is to be 
used with that servant object. 

DESCRIPTION OF THE PREFERED EMBODIMENTS 

The present invention relates to an object adaptor 
that is able to interact with and make use of a subset of 
all available features within a distributed object system 
through the use of subcontracts. Such an object adaptor 
need not necessarily supply an exhaustive fixed set of 
all features for all objects; to the contrary, such an object 
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adaptor is designed to supply a smaller subset of fea- 
tures, resulting in a lower overhead for the CPU, quicker 
response, etc. 

This low-overhead (or "light-weight") object adaptor 
provides various functionalities for use with objects in 
the context of subcontracts. By way of example, these 
functionalities include implementation activation, object 
reference creation and object invocation. The creation 
of object references and implementation activation in 
accordance with one embodiment of one aspect of the 
present invention will be described below with reference 
to Figures 6 through 11. The functionality relating to 
object invocation is discussed below with reference to 
an embodiment illustrated in Figures 12a, 12b and 13. 
In another aspect of the invention specialized data 
structures are provided that are arranged to facilitate 
efficient implementation of these functionalities. 

As discussed above, the distributed object system 
may provide various features such as security or server 
activation for use by individual objects. These features 
are grouped into sets, and each set of one or more fea- 
tures is termed a subcontract. Each subcontract in turn 
is identified by a Subcontract Identifier, that may be a 
number or any other suitable identifier. For example, as 
illustrated in Figure 2, Subcontract 1 may indicate that a 
clean shutdown should not be provided, that an authen- 
tication protocol such as MD5 should be used, that 
objects should have persistence and that server activa- 
tion should be turned on. Thus, Subcontract 1 identifies 
four features available for an object, and whether these 
features are present (or turned on or off), are further 
qualified or have a specific value. A set of features is 
referred to herein as "a quality of service." Thus, each 
Subcontract Identifier identifies a specific quality of 
service. In the embodiment shown, the features that 
define a specific quality of service are identified in a list 
of name-value pairs. 

Referring next to Figure 2, a subcontract registry 
data structure 200 in accordance with one embodiment 
of the present invention will be described. The subcon- 
tract registry is used to store the information that asso- 
ciates a particular quality of service with a unique 
Subcontract Identifier and with its associated subcon- 
tract client representation create function. This table 
200 is termed a subcontract registry in that it registers 
and makes available for searching all of the available 
subcontracts within the system. In this fashion, the table 
is advantageous in that it allows any number of imple- 
mentations to be associated with a particular subcon- 
tract, as will be discussed below with reference to 
Figure 3. it should be appreciated that although a pre- 
determined number of permutations of features within a 
system are possible, the subcontract registry may only 
identify a subset of these possible subcontracts that 
have been implemented within the distributed object 
system. This table 200 may be implemented as a hash 
table, linked list or any other suitable data structure. 

The subcontract registry 200 includes a Subcon- 



tract Identifier column 202, an associated quality of 
service list column 204, a subcontract client representa- 
tion create function column 206, and location indicators 
to other functions 208. Each row of the table 210 is 

5 termed a Subcontract Meta Object and, by way of 
example, may be implemented as a C++ object. In the 
embodiment shown, a plurality of Subcontract Meta 
Objects 212, 214 and 216 are provided in the subcon- 
tract registry 200. The first Subcontract Meta Object 212 

w has a Subcontract Identifier of "1" and is thus identified 
as Subcontract 1. Subcontract 1 lists the following fea- 
tures for its quality of service: clean shutdown, security, 
persistence and server activation. The name-value 
pairs in this quality of service list indicates that a clean 

/5 shutdown will not be implemented, that for security, an 
authentication protocol using MD5 will be used, that 
persistence is turned on and that server activation is 
present. In column 206, Subcontract 1 has a location 
indicator to its associated subcontract client representa- 

20 tion create function, Client Rep Createl. Column 208 
includes a plurality of location indicators to various other 
functions associated with this Subcontract Meta Object 
such as location indicators to an unmarshal function, a 
destringify function and a bad server identifier handler. 

25 Each name-value pair contains a name that indi- 
cates a particular feature of the system, and a value for 
that name indicating whether the feature is present or 
not or which aspect of the feature is to be used. For 
example, for the feature of transactions, its value may 

30 either be YES or NO, indicating whether this feature is 
turned on or off. However, for the security feature, its 
value may be a specific aspect of security such as 
authentication followed by a particular protocol to use 
such as MD5, Kerberos, or SPKM. The name field may 

35 be represented by a string variable, and the value field 
may also be a string or a number. Thus, a specific qual- 
ity of service chosen by a developer for use with an 
object or objects within an application indicates the fea- 
tures that the developer wishes to take advantage of. 

40 Because these features may be unique to each object, 
it is necessary to have a specific create function for 
each quality of service that will create an object location 
indicator to the particular object being referenced. 

The second illustrated Subcontract Meta Object 

45 214 is the Subcontract Meta Object for Subcontract 2. 
The quality of service list for this subcontract indicates 
that a clean shutdown will be implemented, that for 
security, an authentication protocol using MD5 will be 
used, that persistence is turned on and that server acti- 

so vation is present. The Subcontract Meta Object 216 
indicates that for Subcontract 3 it will allow clean shut- 
downs, that for security, an authentication protocol 
using MD5 will be used, that persistence is present and 
that server activation will also be turned on. 

55 The subcontract registry 200 will typically have a 
group of associated functions that are used to organize 
and access the registry By way of example, the associ- 
ated functions may include an Add function, a Find func- 
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tion, a Get First function and a Get Next function. The 
Add function may be used to add a new quality of serv- 
ice to the table. In the described embodiment, the Add 
function takes as arguments a Subcontract Identifier 
and a Subcontract Meta Object. A Find function takes 
as an argument a Subcontract Identifier and returns the 
Subcontract Meta Object associated with that identifier. 
The functions Get First and Get Next return the appro- 
priate Subcontract Meta Object and are used to iterate 
over the entire table and thus search it completely for a 
particular quality of service. This subcontract registry 
may be used in the following manner. When a client 
wishes to make a call to a particular server object, the 
subcontract registry may be used to look up the Sub- 
contract Identifier associated with that server object and 
then to call the appropriate subcontract client represen- 
tation create function in order to create an object refer- 
ence to the particular server object using the 
appropriate features. 

Each object in the system is associated with an 
implementation definition. Each implementation defini- 
tion for an object includes such information as the name 
of the implementation, which subcontract to use in cre- 
ating the object, the Interface Identifier for the object , a 
set of call back functions and skeleton information. 
These call back functions may be stored in an object. 
Such information for an implementation definition may 
be stored in a wide variety of manners. By way of exam- 
ple, such information may be stored in an implementa- 
tion registry table. 

Figure 3 shows an implementation registry 250 in 
accordance with one embodiment of the present inven- 
tion. The implementation registry has entries corre- 
sponding to various implementation definitions. 
Through the use of this table, an implementer of an 
object server will be able to provide multiple, different 
implementations of a single ORB object type in the 
same object server. That is, one object type may hake 
various implementations that are identified by distinct 
Implementation Identifiers. Each implementation 
defines the behavior for all of the operations and 
attributes of the interface that it supports. In other 
words, each interface may have many implementations. 
Therefore, each Implementation Identifier represents a 
distinct implementation for an object that uses a partic- 
ular subcontract. And each implementation may use a 
different subcontract by way of a subcontract location 
indicator in the implementation registry as will be dis- 
cussed below. In this fashion, the implementation regis- 
try is advantageous in that it allows an invoking function 
to choose a particular implementation which in turn may 
use a desired subcontract of the subcontract registry. 

Each implementation definition represents an entry 
in the implementation registry that contain location indi- 
cators to the different data stored. The implementation 
registry 250 includes an Implementation Identifier col- 
umn 252 that names the implementation, a Subcontract 
Meta Object column 254, an Interface Identifier column 



256, a column 257 for a Ready Flag, a call back func 
tions column 258, and a skeleton information column 
259. The Implementation Identifier is a name for the 
implementation that is supplied by the developer when 
5 an implementation definition is created. The Subcon- 
tract Meta Object is a location indicator from a particular 
implementation definition to a Subcontract Meta Object 
contained in the subcontract registry 200. The Interface 
Identifier is a fixed globally unique name of the type of a 
10 particular interface. The Ready Flag will be set for a par- 
ticular implementation definition when the implementa- 
tion has been prepared as will be described below with 
reference to Figure 8. If the Ready Flag is not set, then 
the dispatch function may have to wait temporarily until 
75 the implementation is ready, as described below with 
reference to Figures 12a and 12b, and specifically in 
step 727 of Figure 12b. The skeleton information pro- 
vides information and functions for use by the skeleton 
associated with this implementation. The call backfunc- 
20 tions are a set of functions associated with each imple- 
mentation. A wide variety of call back functions may be 
associated with a particular implementation. By way of 
example, the call back functions Lookup, Post Invoke, 
Revoke, Deactivate and Shutdown will be illustrated. 
25 The Lookup function takes as an argument a User 
Key and returns a location indicator to a servant, which 
may be NULL if no corresponding object exists. If the 
object is found the invocation continues. If not, an 
exception is returned to the client. The User Key is ref- 
30 erence data supplied by the developer and may be any 
arbitrary data. The User Key forms part of the object ref- 
erence as will be explained below with reference to Fig- 
ure 5. The Post Invoke function takes as an argument a 
user key and returns no value. It may execute various 
35 operations that the developer wishes to perform after 
the invocation of an object. The Revoke function takes 
as an argument the User Key and performs the function 
of preventing an object from being referred to. The 
Deactivate function takes as arguments the User Key 
40 and a deactivate closure. The deactivate closure is a 
procedure that enables the ORB to do some internal 
clean up once the object has been deactivated by the 
body of the deactivate function. Essentially, the deacti- 
vate function itself serves to make the object inaccessi- 
45 ble. The Shutdown function is used to shutdown a 
particular implementation definition by removing all 
servant objects if necessary. Each set of call back func- 
tions 258 associated with an implementation definition 
may be represented in an object that contains these 
50 functions. 

Referring again to Figure 3. shown in particular in 
the implementation registry 250 is an implementation 
definition 262. This definition is for a PRINTER imple- 
mentation of the interface PRINTER INTERFACE and it 
55 has a location indicator 266 to Subcontract 1 of the sub- 
contract registry. It also has five unique call back func- 
tions, and a unique skeleton dispatch function. Also 
shown is an implementation definition 264 for a 
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MODEM implementation that has a location indicator to 
its corresponding subcontract, and that implements the 
interface identified by MODEM INTERFACE. 

Associated with this implementation registry 250 
are various functions used to organize and access the s 
registry. By way of example, the function Add may be 
used to add an implementation definition with a particu- 
lar Implementation Identifier to the implementation reg- 
istry The function Find may take as an argument an 
Implementation Identifier and will search through the io 
registry in order to return the corresponding implemen- 
tation definition. 

Figure 4 at 300 shows how the subcontract registry 
200 and the implementation registry 250 interact with 
one another. The subcontract registry 200 registers var- is 
ious subcontracts by having Subcontract Meta Object 
entries such as 212, 214 and 216. etc. Each of these 
Subcontract Meta Objects identifies a unique set of fea- 
tures of the system. For example, Subcontract Meta 
Object 1 identifies Subcontract 1 that identifies the fea- 20 
tures security 302, persistence 304 and clean shutdown 
306. Similarly, Subcontract 2 identifies the feature 
server activation 308. Subcontract 3 identifies the fea- 
tures clean shutdown 306, server activation 308 and 
transactions 310. 25 

The interaction between the two takes place as fol- 
lows. The implementation registry 250 identifies various 
implementation definitions such as PRINTER 262 and 
MODEM 264. Each of these implementation definitions 
references a single one of the Subcontract Meta 30 
Objects through, for example, link 266. It may be possi- 
ble for a particular Subcontract Meta Object to be refer- 
enced by more than one implementation definition. For 
example, both the PRINTER and the MODEM defini- 
tions reference Subcontract 1 through Subcontract 35 
Meta Object 1. 

Figure 5 at 150 shows the object reference 
described above in the overview. It should also be noted 
that the subcontract Identifier 158 identifies not only 
which subcontract the object will utilize but also identi- 40 
fies a particular Subcontract Meta Object in the subcon- 
tract registry through column 202 of Figure 2. The 
Implementation Identifier 162 identifies the name of the 
implementation for this object and also indicates an 
implementation definition by way of column 252 of the 45 
implementation registry of Figure 3. 

Figure 6 shows a procedure 400 that describes the 
typical steps needed to create objects for which a server 
may dispatch requests. The steps of creating an imple- 
mentation definition and preparing it typically occur so 
when the server process is initialized. Object references 
are created in the server and given to the client in 
response to requests on other objects which are usually 
referred to as factory objects. Factory objects are usu- 
ally well-known objects that are created when a server ss 
is installed, or else when it initializes. These well-known 
objects are typically registered with a naming service so 
that clients can find them. Thus, there are preferably two 



cases in which step 406 below is called: as part of the 
server installation or initialization, or in an operation on 
a factory object implemented in the server. An imple- 
mentation definition is created by filling out a row of the 
implementation registry that will then be accessed by 
an invocation. Once ready this implementation may 
receive invocations upon its objects. If the implementa- 
tion is no longer able to receive invocations, it may be 
deactivated, as discussed below with reference to Fig- 
ure 10. or the ORB may wish to shutdown as discussed 
below with reference to Figure 11. 

In a first step 402 of Figure 6 the create implemen- 
tation definition function is called. This function will take 
as arguments a desired quality of service list, a name 
for an implementation and skeleton information, and will 
return an implementation definition. This step will be 
explained in more detail below with reference to Figure 
7. In step 404 a prepare implementation definition func- 
tion is called. This function takes as arguments an 
implementation definition and a set of call back func- 
tions for that implementation definition in order to install 
these functions in the implementation definition. It will 
be explained in more detail below with reference to Fig- 
ure 8. Once the implementation is ready instep 406 a 
create object reference function is called. This function 
takes as arguments an implementation definition and 
the User Key and returns an object reference. This cre- 
ate object reference function produces an object refer- 
ence to a servant that may or may not exist according to 
the subcontract specified. This step will be explained in 
more detail below with reference to Figure 9. 

Once an object has been created by producing its 
object reference the object is available for use. At this 
point the client may make use of the server object and 
other processing may occur. Thus step 408 indicates a 
wait state in which the system continues processing of 
an application until the occurrence of two possible situ- 
ations. These situations are described in steps 410 and 
414. Step 410 checks whether any more invocations for 
this particular implementation are desired. In other 
words, if the developer no longer has any use for this 
object it will be removed in step 412. Otherwise, the sys- 
tem continues processing and uses this implementa- 
tion. In step 412 the deactivate implementation function 
is called. This function takes as an argument an imple- 
mentation definition and removes that implementation. 
The deactivate implementation function will be 
explained in more detail below with reference to Figure 
10. 

Occasionally, the object request broker (ORB) may 
wish to shut down the server. If not, then the system 
continues processing as in step 408. However, if the 
system is to be shut down then in step 416 the server 
shutdown function is called. This server shutdown func- 
tion will be explained in more detail below with reference 
to Figure 1 1 . 

Referring next to Figure 7, a create implementation 
definition function suitable for implementing step 402 in 
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Figure 6 will be described in more detail. The create 
implementation definition function takes as arguments a 
quality of service list, a name for an implementation and 
an Interface Identifier. In step 452 the desired quality of 
service list is used to search through the subcontract 5 
registry and match the quality of service list of an exist- 
ing Subcontract Meta Object. This step may be per- 
formed by searching each entry in the subcontract 
registry using the subcontract registry functions as dis- 
cussed above. In step 454 an entry is created in the 70 
implementation registry using the Interface Identifier 
and the name for the implementation as the Implemen- 
tation Identifier. In step 456 the Subcontract Meta 
Object field for this new entry is updated to point to the 
identified Subcontract Meta Object found in step 452. 75 
Next, in step 457 all skeleton information is stored in this 
new entry, including the skeleton dispatch function 
unique for this implementation definition. After this step 
this new implementation definition is returned and this 
function is done and control returns to step 404 of Fig- 2 o 
ure 6. 

Referring next to Figure 8. a prepare implementa- 
tion definition function suitable for implementing step 
404 in Figure 6 will be described in more detail. This 
function takes as arguments an implementation defini- 25 
tion and a set of associated call back functions. In step 
484 the implementation definition is used to determine 
the corresponding Implementation Identifier. Next, in 
step 486 these call back functions are inserted in the 
implementation registry at the entry corresponding to 30 
the found Implementation Identifier. In step 488 the 
implementation Ready Flag is set to YES to indicate 
that this implementation is now ready for use. Because 
the implementation is now ready, in step 490 any wait- 
ing procedures are now unblocked and may use this 35 
implementation. For example, step 727 of the invocation 
procedure of Figure 12b must wait until the implementa- 
tion is ready. After this step 490 the function is done and 
control returns to step 406 of Figure 6. 

Referring next to Figure 9, a create object reference 40 
function suitable for implementing step 406 in Figure 6 
will be described in more detail. This function takes as 
arguments an implementation definition and a User Key. 
It will eventually create and return an object reference 
by using the subcontract client representation create 45 
function described below. In step 502 the implementa- 
tion definition is used to reference its corresponding 
entry in the implementation registry in order to produce 
the corresponding Subcontract Meta Object location 
indicator that points to the appropriate Subcontract so 
Meta Object in the subcontract registry. In step 504 the 
subcontract client representation create function corre- 
sponding to the entry in the table for this found Subcon- 
tract Meta Object is returned. In step 506 this 
subcontract client representation create function is 55 
called with the User Key and the received implementa- 
tion definition as arguments. This client representation 
create function creates an object reference for a servant 



(that may or may not yet exist) corresponding to the 
Interface Identifier and named Implementation Identifier 
of the received implementation definition. Because this 
client representation create function is unique to each 
subcontract, this step utilizes the appropriate features of 
the corresponding subcontract in order to return the 
object reference. In step 508 this object reference cre- 
ated is returned and the function is done and control 
returns to step 408 of Figure 6. 

Referring next to Figure 10, a deactivate implemen- 
tation function suitable for implementing step 41 2 in Fig- 
ure 6 will be described in more detail. This function take 
as an argument an implementation definition. In step 
520 the implementation definition is used to produce the 
corresponding Implementation Identifier. In step 522 the 
entry in the implementation registry corresponding to 
this Implementation Identifier is removed. This removal 
effectively prevents this implementation of an interface 
from being used because the implementation is no 
longer present in the implementation registry. After this 
step the function is done and control returns to the end 
of Figure 6. 

Referring next to Figure 1 1 , a shut down function 
suitable for implementing step 416 in Figure 6 will be 
described in more detail. This shutdown function is used 
to shutdown all implementation of objects within the 
ORB. Step 540 introduces a looping structure that will 
step through all entries in the implementation registry. 
An index J is first set equal to the first entry in the imple- 
mentation registry. Upon each iteration of this loop, the 
index J will be set to the next entry in the table. Step 540 
also tests whether the last entry has been processed, if 
so, then this function is done. In step 542 the shutdown 
call back function corresponding to a particular imple- 
mentation definition at entry J is called in order to shut- 
down this particular implementation. Once all 
implementations have been shutdown, then the ORB 
may safely cease processing. After this step the func- 
tion is done and control returns to the end of Figure 6. 
Now that an embodiment of the create object reference 
function of Figure 6 has been described, the dispatch 
function will be described. 

Figures 12a, 12b and 13 illustrate an embodiment 
of a procedure for performing object invocation. This 
procedure makes use of the implementation and sub- 
contract registries in order to take advantage of subcon- 
tracts in accordance with one of the goals of the present 
invention. Object invocation is the process by which a 
client invokes an operation or accesses an attribute of a 
server object, a call is made through the ORB to the 
server object, the operation is invoked upon the server 
object, and a result is returned to the client (if required). 
Once the mechanisms on the client side have proc- 
essed this request and passed the request to the client 
transport layer, the client transport layer sends the 
request to the server's transport layer. Figures 12a, 12b 
and 13 describe how the transport layer calls a particu- 
lar dispatch function of a subcontract in order to invoke 
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the server object. Each subcontract has a unique dis- 
patch function that performs the steps that will be 
described below. The procedure will use the implemen- 
tation registry in order to find the appropriate lookup 
function and the appropriate skeleton dispatch function 
for that implementation. The subcontract registry will 
also be used to provide a bad server identifier handler 
function corresponding to a particular subcontract if 
necessary. 

Figure 12a begins by having the transport layer call 
the dispatch function for a particular subcontract using 
the subcontract identifier. Due to the client's invocation 
on the object reference, the transport layer has been 
provided with a marshal buffer that contains among 
other information, the object key for the server object. 
This object key contains information as shown in Figure 
5. The marshal buffer also contains the name of the 
method to be invoked upon the server object and any 
necessary arguments. As the subcontract identifier is 
contained within the object key as shown in Figure 5, 
the transport layer is able to "peek" at this subcontract 
identifier in order to determine which subcontract is 
appropriate and which dispatch function should be 
called. 

In step 702 this subcontract identifier is extracted 
from the object reference in the marshal buffer. The 
process of extraction means that this information is 
taken from the marshal buffer and is no longer present 
in the marshal buffer. Next, in step 704 this extracted 
subcontract identifier is compared with the current sub- 
contract that is being utilized in order to verify that the 
appropriate subcontract is being used. As described 
above, during object development, an application devel- 
oper has associated a particular subcontract with an 
object by using a subcontract identifier. 

In step 706 the server identifier is extracted from 
the object reference in the marshal buffer. The server 
object that is the subject of the invocation is present 
within a particular server process on a host computer; 
thus, it is important to verify that this server identifier 
matches with the identifier of the current server. In step 
708 this extracted server identifier is compared with the 
identifier of the current server in order to determine if 
the object reference is referencing the appropriate 
server process. Step 710 determines if the extracted 
server identifier is valid and does match with the current 
server. If not, this indicates that the server identifier is 
invalid and appropriate action should be taken. This 
action may be performed by a bad server identifier han- 
dler function. Step 712 determines if an appropriate bad 
server identifier handler is registered in the subcontract 
meta object. Because the subcontract identifier has 
already been extracted from the object reference, this 
step may be performed by using the subcontract regis- 
try of Figure 2. The subcontract identifier acts as a key 
to a particular row of this table that allows a search of 
column 208 in order to determine if the bad server iden- 
tifier handler is present. If the handler is not present, 



then the system throws an exception relating to this sit- 
uation in step 716 and the dispatch function ends. If, 
however, the handler is registered in the subcontract 
meta object, then in step 714 this bad server identifier 

5 handler is called with the subcontract identifier and the 
marshal buffer as arguments. After this step, the dis- 
patch function ends. 

Returning now to step 710, if the extracted server 
identifier does match with the current server, then con- 

70 trol moves to step 718. In step 718 the implementation 
identifier is extracted from the object reference in the 
marshal buffer. In step 720 this extracted implementa- 
tion identifier is used as a key to the implementation 
registry of Figure 3 in order to find the appropriate 

75 implementation definition. The use of the implementa- 
tion registry is explained above with reference to Figure 
3. This step 720 may be performed by searching 
through column 252 of the implementation registry of 
Figure 3 in order to determine if the implementation 

20 identifier is present in the table. If in step 722 it is deter- 
mined that the implementation definition is not found 
then in step 724 an exception is thrown relating to this 
condition and the dispatch function ends. If however, the 
implementation definition is found then the operation 

25 may proceed with use of the definition. 

However, even if an implementation definition is 
found, it may not necessarily be ready for use. An imple- 
mentation definition is ready, or prepared, if the prepare 
implementation definition step 404 of Figure 6 has been 

30 executed. Once this step has been executed, the Ready 
Flag will be set. Step 726 tests whether this Ready Flag 
has been set. If not, then in step 727 the dispatch func- 
tion enters a wait state in which it waits for the imple- 
mentation definition to become ready. Once the 

35 implementation definition is ready then control moves 
from step 726 to step 728. In step 728 the lookup func- 
tion from the implementation definition is extracted. This 
lookup function is one of the call back functions of col- 
umn 258 of Figure 3 and will be used to produce a local 

40 location indicator to the servant. In step 730 the User 
Key is extracted from the object reference in the mar- 
shal buffer. Next, in step 732 the lookup function is 
called with the User Key as an argument. Once this 
function has executed it will return a location indicator to 

45 the servant. This location indicator may be implemented 
in the local language of the server. By way of example, 
this location indicator may be a C++ object pointer that 
references the servant C++ object. 

Now that a local location indicator has been 

so obtained to the servant object the dispatch function is 
ready to execute the appropriate method upon the serv- 
ant object that was originally requested by the client. In 
step 733 the method descriptor is extracted from the 
marshal buffer. The method descriptor is a representa- 

55 tion from the client's point of view of that particular 
method name defined upon the servant that the client 
wishes to invoke. In step 734 the skeleton dispatch 
function is extracted from the implementation definition. 
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This skeleton dispatch function may be found in the 
implementation registry in column 259 of Figure 3. In 
step 736 this skeleton dispatch function is called with 
the arguments servant location indicator, marshal buffer 
and the method descriptor. This function will be 5 
explained in more detail below with reference to Figure 
1 3. The skeleton dispatch function achieves the result of 
executing the method upon the servant that the client 
requested be performed. Once this operation has taken 
place the invocation of the server object by the client w 
has finished. However, an additional function may be 
executed. The post invoke function is a developer 
defined function for each implementation that achieves 
a functionality that the developer wishes. In step 738 
this post invoke function is extracted from the implemen- is 
tation definition. In step 740 this post invoke function is 
called with the User Key as an argument. The post 
invoke function may be used by the developer to per- 
form a particular action after the invocation of an object. 
For example, Lookup/ Post-Invoke may count the 2 o 
number of active invocations on a particular server. This 
is useful for managing the life cycle of servant objects. 

Referring next to Figure 13, a skeleton dispatch 
function suitable for implementing step 736 in Figure 
12b will be described in more detail. This function first 25 
begins in step 802 in which an unmarshaiing mecha- 
nism is selected based upon the method descriptor. The 
unmarshaiing mechanism may be a sequence of code 
that is selected by a switch statement for example. As 
other information has already been extracted from the 30 
marshal buffer, the only information remaining in the 
marshal buffer at this point are the arguments of the 
method to be called. In step 804 the selected unmar- 
shaiing mechanism is used to unmarshal the remainder 
of the marshal buffer into the invocation arguments. In 35 
step 806 the method descriptor is used to invoke the 
method defined upon the servant using the invocation 
arguments. This step has the effect of executing the 
method that was originally requested by the client. It is 
possible that this method returns no value at all and per- 40 
forms other functions, or may be that the method 
returns a value to the client. Step 808 determines if the 
method produces a reply. If not, then this function is 
done. If so, then control moves to step 810. In step 810 
an appropriate marshalling mechanism is selected cor- 4t 
responding to the method descriptor. In step 812 the 
selected marshalling mechanism is used to marshal the 
reply into the marshal buffer. At this point the marshal 
buffer is ready to be returned through the transport layer 
to the client. After this step, this function is done and st 
control returns to step 738 of Figure 12b. 

The present invention as described above employs 
various process steps involving data stored in computer 
systems. These steps are those requiring physical 
manipulation of physical quantities. Usually, though not s. 
necessarily, these quantities take the form of electrical 
or magnetic signals capable of being stored, trans- 
ferred, combined, compared, and otherwise manipu- 



lated. It is sometimes convenient, principally for reasons 
of common usage, to refer to these signals as bits, val- 
ues, elements, variables, characters, data structures, or 
the like. It should be remembered, however, that all of 
these and similar terms are to be associated with the 
appropriate physical quantities and are merely conven- 
ient labels applied to these quantities. 

Further, the manipulations performed are often 
referred to in terms such as identifying, running, or com- 
paring. In any of the operations described herein that 
form part of the present invention these operations are 
machine operations. Useful machines for performing 
the operations of the present invention include general 
purpose digital computers or other similar devices. In all 
cases, there should be borne in mind the distinction 
between the method of operations in operating a com- 
puter and the method of computation itself. The present 
invention relates to method steps for operating a com- 
puter in processing electrical or other physical signals to 
generate other desired physical signals. 

The present invention also relates to an apparatus 
for performing these operations. This apparatus may be 
specially constructed for the required purposes, or it 
may be a general purpose computer selectively acti- 
vated or reconfigured by a computer program stored in 
the computer. The processes presented herein are not 
inherently related to any particular computer or other 
apparatus. In particular, various general purpose 
machines may be used with programs written in accord- 
ance with the teachings herein, or it may be more con- 
venient to construct a more specialized apparatus to 
perform the required method steps. The required struc- 
ture for a variety of these machines will appear from the 
description given above. 

In addition, the present invention further relates to 
computer readable media that include program instruc- 
tions for performing various computer-implemented 
operations. The media and program instructions may be 
those specially designed and constructed for the pur- 
poses of the present invention, or they may be of the 
kind well known and available to those having skill in the 
computer software arts. Examples of computer reada- 
ble media include, but are not limited to, magnetic 
media such as hard disks, floppy disks, and magnetic 
tape; optical media such as CD-ROM disks; magneto- 
optical media such as floptical disks; and hardware 
devices that are specially configured to store and per- 
form program instructions, such as read-only memory 
devices (ROM) and random access memory (RAM). 
Examples of program instructions include both machine 
code, such as produced by a compiler, and files contain- 
ing higher level code that may be executed by the com- 
puter using an interpreter. 

Figure 14 illustrates a typical computer system in 
accordance with an embodiment of the present inven- 
tion. The computer system 100 includes any number of 
processors 102 (also referred to as central processing 
units, or CPUs) that are coupled to storage devices 
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including primary storage 106 (typically a random 
access memory, or RAM), primary storage 104 (typi- 
cally a read only memory, or ROM). As is well known in 
the art, primary storage 104 acts to transfer data and 
instructions uni-directionally to the CPU and primary 
storage 106 is used typically to transfer data and 
instructions in a bi-directional manner. Both of these pri- 
mary storage devices may include any suitable of the 
computer-readable media described above. A mass 
storage device 108 is also coupled bi-directionally to 
CPU 102 and provides additional data storage capacity 
and may include any of the computer-readable media 
described above. The mass storage device 108 may be 
used to store programs, data and the like and is typically 
a secondary storage medium such as a hard disk that is 
slower than primary storage. It will be appreciated that 
the information retained within the mass storage device 
108, may, in appropriate cases, be incorporated in 
standard fashion as part of primary storage 106 as vir- 
tual memory. A specific mass storage device such as a 
CD-ROM 114 may also pass data uni-directionally to 
the CPU. 

CPU 102 is also coupled to an interface 110 that 
includes one or more input/output devices such as such 
as video monitors, track balls, mice, keyboards, micro- 
phones, touch-sensitive displays, transducer card read- 
ers, magnetic or paper tape readers, tablets, styluses, 
voice or handwriting recognizers, or other well-known 
input devices such as, of course, other computers. 
Finally, CPU 102 optionally may be coupled to a compu- 
ter or telecommunications network using a network con- 
nection as shown generally at 1 12. With such a network 
connection, it is contemplated that the CPU might 
receive information from the network, or might output 
information to the network in the course of performing 
the above-described method steps. The above- 
described devices and materials will be familiar to those 
of skill in the computer hardware and software arts. 

Although the foregoing invention has been 
described in some detail for purposes of clarity of 
understanding, it will be apparent that certain changes 
and modifications may be practiced within the scope of 
the appended claims. For instance, the present inven- 
tion may be practiced within any suitable distributed 
object environment. And the subcontract registry and 
implementation registry tables may be represented in 
different forms or may even be combined into one data 
structure while still accomplishing the goals of the 
present invention. Also, although the create object refer- 
ence and object invocation flow charts describe one set 
of functions that utilize the notion of a subcontract within 
the described low overhead object adaptor, it is contem- 
plated that other similar functions may use subcontracts 
through a form of the subcontract registry and imple- 
mentation registry tables as described above. There- 
fore, the described embodiments should be taken as 
illustrative and not restrictive, and the invention should 
not be limited to the details given herein but should be 



defined by the following claims and their full scope of 
equivalents. 

Claims 

5 

1. A computer-implemented method of creating an 
object reference for a distributed server object 
within a distributed object computing system, the 
distributed object computing system utilizing a fea- 

10 ture registry for invoking implementations of server 
objects, and the distributed object computing sys- 
tem providing a plurality of features for use in invok- 
ing the implementations of server objects, the 
method comprising the steps of: 

15 

receiving a request that an object reference be 
created for a server object; 

identifying a subcontract entry in the feature 
20 registry, the feature registry including a plurality 

of subcontract entries each associated with a 
feature set including at least one of the plurality 
of features, the subcontract entry being associ- 
ated with the server object reference to be cre- 
25 ated and being arranged to identify a feature 

set having at least one feature to be utilized in 
invoking an implementation of the server 
object; 

30 identifying a create function associated with the 

identified subcontract entry, the create function 
being responsible for creating the server object 
using the feature set identified by the identified 
subcontract entry; 

35 

invoking the create function in order to produce 
an object reference for the server object; and 

returning the produced object reference. 

40 

2. A method as recited in claim 1 wherein each feature 
set includes at least one feature name-value pair, 
wherein each feature name-value pair includes: 

45 a feature name that identifies an associated 

one of the plurality of features; and 

a value that further qualifies the associated fea- 
ture. 

50 

3. A method as recited in claim 1 wherein the step of 
invoking the identified create function includes 
passing a user-identrf ied key to the create function. 

55 4. A method as recited in claim 1 wherein the distrib- 
uted object computing system also utilizes an 
implementation registry, the implementation regis- 
try including a plurality of implementation defini- 



14 



27 



EP 0 817 025 A2 



28 



tions, each implementation definition including an 
implementation identif ier and a subcontract location 
indicator that indicates a unique subcontract entry 
in the feature registry, wherein the method further 
comprises the step of creating an implementation 5 
definition for the implementation of the server 
object to be created. 

A computer-implemented method of invoking an 
object method defined on a distributed server 10 
object within a distributed object computing system, 
the distributed object computing system utilizing an 
implementation registry including a plurality of 
implementation definitions, each implementation 
definition defining an implementation for an inter- is 
face within the distributed object computing system, 
each implementation definition having an imple- 
mentation identifier and associated functions, the 
method comprising the steps of: 

20 

receiving a marshal buffer containing an object 
reference to the server object; 

extracting an implementation identifier from the 
object reference in the marshal buffer; 25 

determining an implementation definition within 
the implementation registry by using the 
extracted implementation identifier as a key; 

30 

calling a lookup function of the implementation 
definition in order to produce a location indica- 
tor to the server object; and 

calling a skeleton dispatch function of the 35 
implementation definition in order to invoke the 
object method defined on the server object. 

A method as recited in claim 5 further comprising 
the steps of: 40 

extracting a subcontract identifier from the 
object reference in the marshal buffer; and 

verifying that the extracted subcontract identi- 45 
fier matches a current subcontract. 

, A method as recited in claim 5 further comprising 
the steps of: 

50 

extracting a server identifier from the object ref- 
erence in the marshal buffer; 
determining if the extracted server identifier 
matches a current server; and 

wherein when it is determined that the 55 
extracted server identifier does not match a 
current server the method further comprises 
the step of calling a bad server identifier han- 



dler function that is identified in a subcontract 
registry. 

8. A method as recited in claim 5 wherein the step of 
calling a lookup function includes the sub-steps of: 

extracting the lookup function from the deter- 
mined implementation definition; and 

extracting a user key from the object reference 
in the marshal buffer. 

9. A method as recited in claim 5 wherein the step of 
calling a skeleton dispatch function includes the 
sub-steps of: 

extracting the skeleton dispatch function from 
the determined implementation definition; and 

extracting a method descriptor from the object 
reference in the marshal buffer. 

10. A feature registry data structure embodied in a* 
computer-readable medium, the feature registry 
used for invoking implementations of server objects 
within a distributed object computing system, the 
distributed object computing system providing a 
plurality of features for use in the implementation of 
server objects, the feature registry including a plu- 
rality of subcontract entries, each subcontract entry 
comprising: 

an implementation identifier naming an imple- 
mentation of an associated server object; 

an interface identifier naming an interface of 
the associated server object that defines oper- 
ations for the associated server object; 

at least one feature identifier, the feature identi- 
fier identifying one of the plurality of features 
that are provided by the distributed object com- 
puting system; and 

a create function for creating an object refer- 
ence for the associated server object in a man- 
ner that utilizes the feature identified by the 
feature identifier within a context that is appro- 
priate in view of the feature identifier. 

1 1. A feature registry data structure as recited in claim 
10 wherein each feature identifier includes a feature 
name-value pair, wherein each feature name-value 
pair includes: 

a feature name that identifies an associated 
one of the plurality of features; and 
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a value that further qualifies the associated fea- 
ture. 



a location indicator to a subcontract object 
associated with the implementation definition; 



12. A subcontract registry data structure embodied in a 
computer-readable medium, the subcontract regis- 5 
try used for creating object references for server 
objects within a distributed object computing sys- 
tem, the distributed object computing system pro- 
viding a plurality of features for use in the creation 

of object references for server objects, the subcon- 10 
tract registry including a plurality of subcontract 
objects, each subcontract object comprising: 

a subcontract identifier identifying the subcon- 
tract object to which it corresponds; is 

at least one feature identifier, the feature identi- 
fier identifying one of the plurality of features 
that are provided by the distributed object com- 
puting system; and 20 

a create function associated uniquely with each 
subcontract object, the create function used to 
create and return an object reference for a 
server object by way of using the features iden- 25 
tified by the feature identifiers associated with 
each subcontract object. 

13. A subcontract registry data structure as recited in 
claim 12 wherein each feature identifier of each 30 
subcontract object is a feature name-value pair, 
wherein each feature name-value pair includes: 

a feature name that identifies an associated 
one of the plurality of features; and 35 

a value that further qualifies the associated fea- 
ture. 

14. A subcontract registry data structure as recited in 40 
claim 12 wherein each subcontract object further 
comprises a bad server identification handler func- 
tion used when it is determined that a server identi- 
fication of a particular object reference does not 
match with a server process. 45 

15. An implementation registry data structure embod- 
ied in a computer-readable medium, the implemen- 
tation registry used for registering a plurality of 
implementation definitions, each implementation 50 
definition defining an implementation for an inter- 
face within a distributed object computing system, 

the distributed object computing system providing a 
plurality of subcontract objects, each implementa- 
tion definition comprising: 55 

an implementation identifier that identifies a 
corresponding implementation definition; 



an interface identifier identifying the interface 
associated with the implementation definition; 
and 

a set of functions associated with the imple- 
mentation definition used for creating and 
invoking a server object that uses - the imple- 
mentation definition. 

16. An implementation registry data structure as 
recited in claim 15 wherein the set of functions 
associated with the implementation definition 
include a skeleton dispatch function used for invok- 
ing a requested method on the server object. 

17. A computer apparatus for use in invoking an imple- 
mentation of a server object within a distributed 
object computing system, the computer apparatus 
comprising: 

a processing unit; , 

an input/output device coupled to the process- 
ing unit; 

a storage device in communication with the 
processing unit, the storage device including a 
feature registry data structure used for invoking 
implementations of server objects within the 
distributed object computing system, the dis- 
tributed object computing system providing a 
plurality of features for use in the implementa- 
tion of server objects, the feature registry 
including a plurality of subcontract entries, 
each subcontract entry including, 

an implementation identifier naming an imple- 
mentation of an associated server object, 

an interface identifier naming an interface of 
the associated server object that defines oper- 
ations for the associated server object, 

at least one feature identifier, the feature identi- 
fier identifying one of the plurality of features 
that are provided by the distributed object com- 
puting system, and 

a create function for creating an object refer- 
ence for the associated server object in a man- 
ner that utilizes the feature identified by the 
feature identifier within a context that is appro- 
priate in view of the feature identifier. 

18. A computer program product comprising a compu- 
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ter-usabte medium having computer-readable code 
embodied thereon for creating an object reference 
for a distributed server object within a distributed 
object computing system, the distributed object 
computing system utilizing a feature registry for 5 
invoking implementations of server objects, and the 
distributed object computing system providing a 
plurality of features for use in invoking the imple- 
mentations of server objects, the computer pro- 
gram product comprising computer-readable w 
program code for effecting the following steps within 
the computer system: 

receiving a request that an object reference be 
created for a server object; )5 

identifying a subcontract entry in the feature 
registry, the feature registry including a plurality 
of subcontract entries each associated with a 
feature set including at least one of the plurality 20 
of features, the subcontract entry being associ- 
ated with the server object reference to be cre- 
ated and being arranged to identify a feature 
set having at least one feature to be utilized in 
invoking an implementation of the server 25 
object; 

identifying a create function associated with the 
identified subcontract entry, the create function 
being responsible for creating the server object 30 
using the feature set identified by the identified 
subcontract entry; 

invoking the create function in order to produce 
an object reference for the server object; and 35 

returning the produced object reference. 

19. A computer program product as recited in claim 18 
wherein each feature set includes at least one fea- 4C 
ture name-value pair, wherein each feature name- 
value pair includes: 

a feature name that identifies an associated 
one of the plurality of features; and 4i 

a value that further qualifies the associated fea- 
ture. 

20. A computer program product as recited in claim 18 s 
wherein the step of invoking the identified create 
function includes passing a user-identified key to 
the create function. 

21. A computer program product as recited in claim 18 £ 
wherein the distributed object computing system 
also utilizes an implementation registry, the imple- 
mentation registry including a plurality of implemen- 



tation definitions, each implementation definition 
including an implementation identifier and a sub- 
contract location indicator that indicates a unique 
subcontract entry in the feature registry, wherein 
the computer program product further comprises 
program code for creating an implementation defini- 
tion for the implementation of the server object to 
be created. 

A computer program product comprising a compu- 
ter-usable medium having computer-readable code 
embodied thereon for invoking an object method 
defined on a distributed server object within a dis- 
tributed object computing system, the distributed 
object computing system utilizing an implementa- 
tion registry including a plurality of implementation 
definitions, each implementation definition defining 
an implementation for an interface within the distrib- 
uted object computing system, each implementa- 
tion definition having an implementation identifier 
and associated functions, the computer program 
product comprising computer-readable program 
code for effecting the following steps within the 
computer system: 

receiving a marshal buffer containing an object 
reference to the server object; 

extracting an implementation identifier from the 
object reference in the marshal buffer; 

determining an implementation definition within 
the implementation registry by using the 
extracted implementation identifier as a key; 

calling a lookup function of the implementation 
definition in order to produce a location indica- 
tor to the server object; and 

calling a skeleton dispatch function of the 
implementation definition in order to invoke the 
object method defined on the server object 

23. A computer program product as recited in claim 22 
further comprising program code for effecting the 
steps of: 

extracting a subcontract identifier from the 
object reference in the marshal buffer; and 

verifying that the extracted subcontract identi- 
fier matches a current subcontract. 

24. A computer program product as recited in claim 22 
further comprising program code for effecting the 
steps of: 

extracting a server identifier from the object ref- 
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erence in the marshal buffer; 

determining if the extracted server identifier 
matches a current server; and 

wherein when it is determined that the 5 
extracted server identifier does not match a 
current server the computer program product 
further comprises program code for effecting 
the step of calling a bad server identifier han- 
dler function that is identified in a subcontract 10 
registry. 

25. A computer program product as recited in claim 22 
wherein the step of calling a lookup function 
includes the sub-steps of: is 

extracting the lookup function from the deter- 
mined implementation definition; and 

extracting a user key from the object reference 20 
in the marshal buffer. 

26. A computer program product as recited in claim 22 
wherein the step of calling a skeleton dispatch func- 
tion includes the sub-steps of: 25 

extracting the skeleton dispatch function from 
the determined implementation definition; and 

extracting a method descriptor from the object 30 
reference in the marshal buffer. 

27. A computer-implemented method of transmitting 
the computer-readable program code as recited in 
claim 18, the method comprising the steps of: 35 

storing the program code onto a computer-usa- 
ble medium; 

receiving a request for the transmission of the 40 
program code; and 

transmitting the program code over a network 
to a remote location on the network. 

45 

28. A computer-implemented method of transmitting 
the computer-readable program code as recited in 
claim 22, the method comprising the steps of: 

storing the program code onto a computer-usa- so 
ble medium; 

receiving a request for the transmission of the 
program code; and 

55 

transmitting the program code over a network 
to a remote location on the network. 
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